In recent years, more and more computing applications are being implemented in distributed environments. A given distributed application may, for example, utilize numerous physical and/or virtualized servers spread among several data centers of a provider network, and may serve customers in many different countries. As the number of servers involved in a given application increases, and/or as the complexity of the application's network increases, failure events of various types (such as the apparent or real failures of processes or servers, substantial delays in network message latency, or loss of connectivity between pairs of servers) are inevitably encountered at higher rates. The designers of the distributed applications are therefore faced with the problem of attempting to maintain high levels of application performance (e.g., high throughputs and low response times for application requests) while concurrently responding to changes in the application configuration state.
Some traditional techniques for managing state information may involve locking the state information to implement application state changes in a consistent manner. Unfortunately, the locking mechanisms used for application state and/or data can themselves often become performance bottlenecks as the application increases in size and complexity. Other techniques may avoid locking, but may have to pause normal operations to propagate changed state information among the application's components. Such “stop-the-world” periods may be problematic, however, especially for latency-sensitive applications that are used for mission-critical workloads by hundreds or thousands of customers spread in different time zones across the world. Even some techniques that avoid locks and stop-the-world pauses may run into bottlenecks when handling very high rates of state transitions.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.